Systems and methods for providing event notifications

ABSTRACT

Methods and apparatus for providing indications of received emergency alert messages to devices within a consumer premises are disclosed. In one embodiment, a consumer premise equipment (CPE) receiving one or more emergency alert messages from a content provider or managed network determines one or more alert responses for one or more devices of the consumer premise network. In one implementation, the responses are based at least in part on the received emergency alert messages themselves. The CPE issues one or more commands to one or more devices present within the consumer premises (which may be for example a home automation system), to indicate the one or more determined alert indication responses, such as auditory alert and visual alert by the one or more devices. Thus, users in the consumer premises may be made aware of an alert message outside of the typical means in which an alert is displayed, such as via a television.

PRIORITY AND RELATED APPLICATIONS

This application is a divisional of and claims priority to co-owned andco-pending U.S. patent application Ser. No. 15/295,810 of the same titlefiled on Oct. 17, 2016, issuing as U.S. Pat. No. 10,269,229 on Apr. 23,2019, which is a divisional of and claims priority to co-owned U.S.patent application Ser. No. 14/059,273 entitled “SYSTEMS AND METHODS FORPROVIDING EMERGENCY ALERTS” filed on Oct. 21, 2013, and issued as U.S.Pat. No. 9,472,091 on Oct. 18, 2016, each of which are incorporatedherein by reference in its entirety. Additionally, this application isrelated to co-pending U.S. patent application Ser. No. 11/299,169 filedDec. 9, 2005 and entitled “EMERGENCY ALERT DATA DELIVERY APPARATUS ANDMETHODS”, which issued as U.S. Pat. No. 7,592,912 on Sep. 22, 2009, andU.S. patent application Ser. No. 12/079,781 filed Mar. 28, 2008 andentitled “METHODS AND APPARATUS FOR CENTRALIZED AND DECENTRALIZEDEMERGENCY ALERT MESSAGING”, which issued as U.S. Pat. No. 8,095,610 onJan. 10, 2012, each of which is incorporated herein by reference in itsentirety.

COPYRIGHT

A portion of the disclosure of this patent document contains materialthat is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor the patent disclosure, as it appears in the Patent and TrademarkOffice patent files or records, but otherwise reserves all copyrightrights whatsoever.

BACKGROUND 1. Technological Field of the Disclosure

The present disclosure relates generally to the field of delivery ofdigital media data (e.g., text, video, and/or audio) over networks suchas the Internet, and specifically in one aspect to delivering emergencyalert system (EAS) data in a network to provide alert indications todevices resident within consumer premises.

2. Description of Related Technology

Emergency Alert System (EAS)—

As is well known, the Emergency Alert System (EAS) is designed to allowfor the rapid and widespread dissemination of information relating to anational or local emergency to the general public. EAS messages aretransmitted for either national, state or local emergencies or otherevents. Examples of these emergencies or events include: severe weatherwatch/storm warning, flash floods, earthquakes/tsunami, and war or other“man made” emergencies.

The EAS was designed in part by the Federal Communications Commission(FCC) in cooperation with the National Weather Service (NWS) and theFederal Emergency Management Agency (FEMA), in order to support theroles of each organization. The FCC provides information tobroadcasters, cable system operators, and other participants in the EASregarding the technical and operational requirements of the EAS.Additionally, the FCC ensures that state and local EAS plans conform toFCC rules and regulations. The NWS provides emergency weatherinformation to alert the public about potential and/or dangerous weatherconditions, or other natural events. FEMA provides direction for stateand local emergency planning officials to plan and implement their rolesin the EAS.

Alerts sent via the EAS may arrive in the form of text, audio and/orvideo content. Depending on the message type, the subscriber'stelevision or set-top box (STB) will display the message in theappropriate format and according to the prescribed method. State andLocal area emergency messages may be transmitted by using EAS Header andEnd of Message Codes. In television environments, the FCC recommendsthat the codes be preceded by an announcement that informs listenersthat an EAS transmission will occur.

In current digital and analog television systems, the EAS transmissionsare received from an over-the-air broadcast. The transmission is thenused in two different ways.

First, for analog broadcasts, all of the analog channels are eitherforce-tuned to a broadcast of the EAS transmission or create theappropriate overlay of text and audio. Nothing is required at thesubscriber (e.g., set-top box) side since all switching and displayfunctionality is performed in the network head-end.

Second, for digital broadcasts, the digital head-end application serverreceives the transmission and creates the proper audio, video and/ortext message for the digital set-top box (DSTB) or other consumerpremises equipment. The DSTB is then responsible for displaying themessage to the user as prescribed by the government mandate. If the EAStransmission is video, then the DSTB will “forcibly” tune its tuner tothe appropriate analog RF channel to receive, decode and display thevideo.

Testing of the EAS system generally comprises a weekly test consistingof an eight-second digital data signal. There is also a monthly testthat utilizes a test script (e.g., “This is a test of the EmergencyAlert System—this is only a test . . . .”). The monthly test script maybe developed locally and may contain information that is relevant to thelocal area into which it is being delivered.

Other features of the digital EAS systems include:

(i) Automatic Operation—The EAS digital system architecture allowsbroadcast stations, cable systems, participating satellite companies,and other services to send and receive emergency information quickly andautomatically even if those facilities are unattended;

(ii) Redundancy—The EAS requires monitoring of at least two independentsources for emergency information. This insures that emergencyinformation is received and delivered to viewers and listeners; and

(iii) Multi-language—EAS digital messages can be automatically convertedinto any language used by the broadcast station or cable system.

“IPTV” and Other Network Paradigms—

Network operators use other types of networks such as Internet protocol(IP) networks to distribute broadcast television programming tosubscribers. This is to be contrasted with more traditional radiofrequency (over-the-air) broadcasts, or in-band delivery via packetizedMPEG-2 program streams. Such IP delivery of broadcast televisionprogramming also requires a method for the delivery of EAS data tosubscriber units such as personal computers (PC), as well as a method todisplay such information on the display monitor (and audio system) ofthese units.

In Internet protocol television (IPTV) and similar distributionnetworks, a wider choice of audio/video codecs is being considered. Forexample, MPEG-2, MPEG-4/H.264 (advanced video codec or “AVC”), are a fewof the possible audio/video compression formats that have been deployed.While these new formats and their associated compression technology isuseful in providing streaming audio/video programs to end users, theseformats do not typically support any type of EAS data delivery. Whilesome video codecs have the ability to embed caption or similarinformation within the video stream (MPEG-2/MPEG-4, etc.), many videocodecs do not. Accordingly, the ability to transport at least some ofthe EAS information to the displaying client outside of the content(e.g., video) packet streams would be of particular utility.

Other Emergency Alert Approaches—

A variety of other approaches to emergency alert transmission over anetwork (and display be user devices) are evidenced in the prior art.See for example, U.S. Pat. No. 3,993,955 to Belcher, et al. issued Nov.23, 1976 entitled “METHOD AND APPARATUS FOR ESTABLISHING EMERGENCYCOMMUNICATIONS IN A TWO-WAY CABLE TELEVISION SYSTEM”, U.S. Pat. No.6,240,555 issued May 29, 2001 to Shoff, et al entitled “INTERACTIVEENTERTAINMENT SYSTEM FOR PRESENTING SUPPLEMENTAL INTERACTIVE CONTENTTOGETHER WITH CONTINUOUS VIDEO PROGRAMS”, U.S. Pat. No. 6,452,492 toDrury issued on Sep. 17, 2002 entitled “EMERGENCY ALERT SYSTEM”, U.S.Pat. No. 6,714,534 to Gerszberg, et al. issued Mar. 30, 2004 entitled“LIFELINE SERVICE FOR HFCLA NETWORK USING WIRELESS ISD”, U.S. Pat. No.6,766,163 issued Jul. 20, 2004 to Sharma entitled “METHOD AND SYSTEM OFDISPLAYING TELETEXT INFORMATION ON MOBILE DEVICES”, U.S. Pat. No.6,771,302 issued Aug. 3, 2004 to Nimri, et al entitled “VIDEOCONFERENCECLOSED CAPTION SYSTEM AND METHOD”, U.S. Pat. No. 6,792,616 issued Sep.14, 2004 entitled “SYSTEM AND METHOD FOR PROVIDING A PLURALITY OFPROGRAMMING SERVICES IN A TELEVISION SYSTEM”, U.S. Pat. No. 6,903,779issued Jun. 7, 2005 to Dyer entitled “METHOD AND SYSTEM FOR DISPLAYINGRELATED COMPONENTS OF A MEDIA STREAM THAT HAS BEEN TRANSMITTED OVER ACOMPUTER NETWORK”, U.S. Patent Application No. 20030121036 to Lock, etal. published on Jun. 26, 2003 entitled “CATV MESSAGING ALERT SYSTEM”,U.S. Patent Publication No. 20040181811 to Rakib published on Sep. 16,2004 entitled “THIN DOCSIS IN-BAND MANAGEMENT FOR INTERACTIVE HFCSERVICE DELIVERY”, U.S. Patent Publication No. 20050015799 to Parkpublished Jan. 20, 2005 entitled “APPARATUS AND METHOD FOR DISPLAYINGOUT-OF-BAND (OOB) CHANNEL INFORMATION IN OPEN CABLE SYSTEM”, U.S. PatentPublication No. 20050151639 to Bulmer published Jul. 14, 2005 entitled“ALERT SYSTEM”, U.S. Patent Publication No. 20050162267 to Khandelwal,et al. published on Jul. 28, 2005 and entitled “EMERGENCY ALERTSERVICE”, and U.S. Patent Publication No. 20050198684 to Stone, et al.published Sep. 8, 2005 entitled “METHOD AND APPARATUS FOR PROVIDING ADSG TO AN OOB TRANSCODER”.

“Digicable” is another prior art system supplied by General Instrument(Motorola) for end-to-end satellite and cable system distributionnetworks. It uses an out-of-band data channel to deliver common systeminformation associated with all in-band channels. Out-of-band traffic inthese systems included: Entitlement Management Messages (EMM) addressedto individual STBs and carrying conditional access secure authorizationinstructions for requested services; Service Information that supportsthe STB navigation application with information about the requestedservice; program guide information to display what is on the variouschannels at various times; an Emergency Alert System messages to causethe STB to display a text message, play an audio message or force tuningto an alert channel.

Additional technological advancements have lead to the proliferation ofhome management systems. Such systems employ communications technologies(such as wireless and Internet communication) to provide remote accessand control to a user's home security and automation systems. In thismanner, information relating to connected devices may be transmittedwirelessly to a user's mobile telephone. For example, home security datamay be collected from security apparatus (such as cameras, sensors,etc.) and provided to a user. Additionally, the foregoing technologiesmay be used to enable a user to control various appliances at the user'shome remotely (via the mobile device). For example, the user may turnon/off lights, air conditioning, and other appliances.

From the foregoing, it is clear that while the prior art has generallyrecognized the need to receive and provide EAS data to client devicesover analog networks, and to enable EAS decode and display capabilitycompatible with an audio/video decoder on a client device, it fails toprovide adequate alerting in circumstances in which a user may beunaware of the EAS message. For example, the user may not be in a closeenough proximity to be made aware of the EAS message, or the responsibledisplay device is not powered on. Accordingly, the user may be at anincreased risk of injury and or loss due to the lack of being informedof the emergency.

Accordingly, what are needed are apparatus and methods that provide amechanism for robustly alerting users of a received EAS message. Suchapparatus and methods should preferably be able to provide emergencyindications to a variety of consumer premises and mobile devices, and ina comprehensive manner. Lastly, these methods and apparatus would incertain implementations require only minimal changes to existingsystems, thereby leveraging the installed infrastructure as much aspossible.

SUMMARY OF THE DISCLOSURE

The present disclosure addresses the foregoing needs by providing, interalia, methods and apparatus for providing indications of emergencymessages received via a network infrastructure to devices within aconsumer premises network.

In one aspect, a method for providing indications of emergency alerts toa device in a consumer premises network is disclosed. In one embodiment,the method includes: receiving one or more emergency alert messages,determining one or more alert indication responses for one or moredevices of the consumer premise network based at least in part on theone or more emergency alert messages, and issuing one or more commandsto the one or more devices to implement the one or more determined alertindication responses.

In a second aspect, an apparatus configured for use in a consumerpremise network is disclosed. In one embodiment, the apparatus includesa processor, one or more interfaces in data communication with theprocessor, and a non-transitory computer readable storage medium with atleast one computer program stored thereon. In one embodiment, the atleast one computer program is configured to, when executed, cause theapparatus to receive an emergency alert system (EAS) message, reformatthe received EAS message into one or more indication alert messages, andtransmit the one or more indication alert messages to one or moredevices in communication with the consumer premise network.

In one variant, the one or more indication alert messages lack messagecontent of the EAS message itself.

In a second variant, the one or more indication alert messages areconfigured to activate one or more functionalities of the one or moredevices, the activated one or more functionalities being related to atleast one aspect of the emergency reflected in the received EAS message.

In a third aspect, a method for displaying indications of an emergencyby a device in a consumer premises network is disclosed. In oneembodiment, the method includes receiving one or more alert commands,the one or more alert commands indicative of an emergency alert messagereceived at the consumer premises network, and performing one or morenotification tasks based at least in part on the received one or morealert commands.

These and other aspects of the disclosure shall become apparent whenconsidered in light of the disclosure provided herein.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a functional block diagram illustrating an exemplary contentdelivery (e.g., cable) network configuration useful with the presentdisclosure.

FIG. 1a is a functional block diagram illustrating one exemplary HFCcable network head-end configuration useful with the present disclosure.

FIG. 2 is a functional block diagram illustrating one exemplarypacket-switched distribution network that useful with the presentdisclosure.

FIG. 3 is graphic representation of an exemplary message exchangeprotocol showing messages exchanged between various elements of thedistribution network of FIG. 2 signal exchange diagram highlighting twoexemplary embodiments of the present disclosure, wherein the emergencyalert messages received by the client devices are explicitly validatedby communication between the client device 220 (as represented by theEAS process 300) and a head-end server process 302 (or alternatively theEAS server process 304).

FIG. 4 is a logic flow diagram illustrating an exemplary embodiment of ageneral method of providing indications of a received emergency alertmessage.

FIG. 4A is a logical flow diagram illustrating another embodiment of themethod of providing indications of a received emergency alert message.

FIG. 4B is a logical flow diagram illustrating yet another embodiment ofthe method of providing indications of a received emergency alertmessage.

FIG. 5 is a functional block diagram illustrating an exemplary consumernetwork premises architecture in accordance with the present disclosure.

FIG. 6 is a functional block diagram illustrating an exemplary consumerpremises equipment (CPE) apparatus in accordance with the presentdisclosure.

All figures © Copyright 2013 Time Warner Cable, Inc. All rightsreserved.

DETAILED DESCRIPTION OF THE DISCLOSURE

Reference is now made to the drawings wherein like numerals refer tolike parts throughout.

As used herein, the term “application” refers generally and withoutlimitation to a unit of executable software that implements a certainfunctionality or theme. The themes of applications vary broadly acrossany number of disciplines and functions (such as on-demand contentmanagement, e-commerce transactions, brokerage transactions, homeentertainment, calculator etc.), and one application may have more thanone theme. The unit of executable software generally runs in apredetermined environment; for example, the unit could comprise adownloadable Java Xlet™ that runs within the JavaTV™ environment.

As used herein, the term “client device” includes, but is not limitedto, set-top boxes (e.g., DSTBs), gateways, modems, personal computers(PCs), and minicomputers, whether desktop, laptop, or otherwise, andmobile devices such as handheld computers, PDAs, personal media devices(PMDs), tablets, “phablets”, and smartphones.

As used herein, the terms “closed captioning” “caption data” or “CCdata” are used to refer to, without limitation, the transcription ofaudio programs, as well as extended data services and VBI data/testsignals, and delivering information such as metadata associated with atelevision program (including inter alia providing URLs for selectiveadvertising, Really Simple Syndication (RSS) feed information related tovideo programs, news clips, stock, weather data, etc.

As used herein, the term “codec” refers to a video, audio, or other datacoding and/or decoding algorithm, process or apparatus including,without limitation, those of the MPEG (e.g., MPEG-1, MPEG-2,MPEG-4/H.264, etc.), Real (RealVideo, etc.), AC-3 (audio), DiVX,XViD/ViDX, Windows Media Video (e.g., WMV 7, 8, 9, 10, or 11), ATI Videocodec, or VC-1 (SMPTE standard 421M) families.

As used herein, the term “computer program” or “software” is meant toinclude any sequence or human or machine cognizable steps which performa function. Such program may be rendered in virtually any programminglanguage or environment including, for example, C/C++, Fortran, COBOL,PASCAL, assembly language, markup languages (e.g., HTML, SGML, XML,VoXML), and the like, as well as object-oriented environments such asthe Common Object Request Broker Architecture (CORBA), Java™ (includingJ2ME, Java Beans, etc.) and the like.

The term “Customer Premises Equipment (CPE)” refers without limitationto any type of electronic equipment located within a customer's oruser's premises and connected to or in communication with a network.

As used herein, the term “digital processor” is meant generally toinclude all types of digital processing devices including, withoutlimitation, digital signal processors (DSPs), reduced instruction setcomputers (RISC), general-purpose (CISC) processors, microprocessors,gate arrays (e.g., FPGAs), PLDs, reconfigurable compute fabrics (RCFs),array processors, and application-specific integrated circuits (ASICs).Such digital processors may be contained on a single unitary IC die, ordistributed across multiple components.

As used herein, the term “display” means any type of device adapted todisplay information, including without limitation CRTs, LCDs, TFTs,plasma displays, LEDs, incandescent and fluorescent devices, orcombinations/integrations thereof. Display devices may also include lessdynamic devices such as, for example, printers, e-ink devices, and thelike.

As used herein, the term “DOCSIS” refers to any of the existing orplanned variants of the Data Over Cable Services InterfaceSpecification, including for example DOCSIS versions 1.0, 1.1, 2.0 and3.0.

As used herein, the terms “emergency alert system (EAS)”, “alert data”,“emergency alert (EA)”, and “emergency broadcast system” refer to,without limitation, the generation and/or delivery of text, audio,and/or visual or video information relating to events, alerts oremergency situations.

As used herein, the term “headend” refers generally to a networkedsystem controlled by an operator (e.g., an MSO) that distributesprogramming to MSO clientele using client devices. Such programming mayinclude literally any information source/receiver including, inter alia,free-to-air TV channels, pay TV channels, interactive TV, and theInternet.

As used herein, the terms “Internet” and “internet” are usedinterchangeably to refer to inter-networks including, withoutlimitation, the Internet.

As used herein, the terms “MSO” or “multiple systems operator” refer toa cable, satellite, or terrestrial network provider havinginfrastructure required to deliver services including programming anddata over those mediums.

As used herein, the terms “network” and “bearer network” refer generallyto any type of telecommunications or data network including, withoutlimitation, hybrid fiber coax (HFC) networks, satellite networks, telconetworks, and data networks (including MANs, WANs, LANs, WLANs,internets, and intranets). Such networks or portions thereof may utilizeany one or more different topologies (e.g., ring, bus, star, loop,etc.), transmission media (e.g., wired/RF cable, RF wireless, millimeterwave, optical, etc.)

and/or communications or networking protocols (e.g., SONET, DOCSIS, IEEEStd. 802.3, ATM, X.25, Frame Relay, 3GPP, 3GPP2, WAP, SIP, UDP, FTP,RTP/RTCP, H.323, etc.).

As used herein, the term “network interface” refers to any signal ordata interface with a component or network including, withoutlimitation, those of the FireWire (e.g., FW400, FW800, etc.), USB (e.g.,USB2), Ethernet (e.g., 10/100, 10/100/1000 (Gigabit Ethernet), 10-Gig-E,etc.), MoCA, Coaxsys (e.g., TVnet™), radio frequency tuner (e.g.,in-band or OOB, cable modem, etc.), Wi-Fi (802.11), WiMAX (802.16),Zigbee®, Z-wave, PAN (e.g., 802.15), power line carrier (PLC), or IrDAfamilies.

As used herein, the term “QAM” refers to modulation schemes used forsending signals over cable networks. Such modulation scheme might useany constellation level (e.g. QPSK, 16-QAM, 64-QAM, 256-QAM, etc.)depending on details of a cable network. A QAM may also refer to aphysical channel modulated according to the schemes.

As used herein, the term “server” refers to any computerized component,system or entity regardless of form which is adapted to provide data,files, applications, content, or other services to one or more otherdevices or entities on a computer network.

As used herein, the term “storage” refers to without limitation computerhard drives, DVR device, memory, RAID devices or arrays, optical media(e.g., CD-ROMs, Laserdiscs, Blu-Ray, etc.), or any other devices ormedia capable of storing content or other information.

As used herein, the term “wireless” means any wireless signal, data,communication, or other interface including without limitation Wi-Fi,Bluetooth, 3G (3GPP/3GPP2), HSDPA/HSUPA, TDMA, CDMA (e.g., IS-95A,WCDMA, etc.), FHSS, DSSS, GSM, PAN/802.15, WiMAX (802.16), 802.20,Zigbee®, Z-wave, narrowband/FDMA, OFDM, PCS/DCS, LTE/LTE-A, analogcellular, CDPD, satellite systems, millimeter wave or microwave systems,acoustic, and infrared (i.e., IrDA).

Overview

In one aspect of the disclosure, methods and apparatus for providingindications of received emergency alert messages to devices within aconsumer premises are disclosed. A consumer premise equipment (CPE)receiving one or more emergency alert messages from a content providerdetermines one or more alert indication responses for one or moredevices of the consumer premise network based at least in part on thereceived emergency alert messages. The CPE issues one or more commandsto one or more devices present within the consumer premise to indicatethe one or more determined alert indication responses, such as auditoryalert and visual alert by the one or more devices. Thus, users in theconsumer premise may be made aware of an alert message outside of thetypical means in which an alert is display, such as via a television.

In one embodiment, the CPE communicates with a home automation system ofthe consumer premise network. The home automation system is configuredto receive the one or more commands which may be configured to directlyrequest desired alert responses or may provide indications of a receivedalert message for the home automation system to determine a desiredalert response. By using the home automation system, devices under thecontrol of the home automation system may be leveraged to increase theeffectiveness in which a user may be notified of received emergencyalert messages.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

Exemplary embodiments of the apparatus and methods of the presentdisclosure are now described in detail. While these exemplaryembodiments are described in the context of the previously mentionedDOCSIS hybrid fiber coax (HFC) cable architecture, the generalprinciples and advantages of the disclosure may be extended to othertypes of networks and architectures where delivery of emergencyinformation or data is required or desirable. Such other networks orarchitectures may be broadband, narrowband, wired or wireless, contentor data, or otherwise. Hence, the following description is merelyexemplary in nature. For example, the disclosure may be practiced over afiber-to-the-home (FTTH) or fiber-to-the-curb (FTTC) system or overfuture satellite or millimeter wave-based network having two-waycapabilities similar to today's digital cable HFC networks.

It will also be appreciated that while described generally in thecontext of a network providing service to a customer or consumer (i.e.,residential) end user domain, the present disclosure may be readilyadapted to other types of environments including, e.g.,commercial/enterprise, and government/military applications. Myriadother applications are possible.

Network-Side Architecture—

Referring now to FIG. 1, an exemplary data-over-cable (DOCSIS) network100, including broadcast IPTV service, is shown. For clarity ofillustration, some details of the network not pertinent to the presentdisclosure have been omitted from FIG. 1. A “master” head-end 102 isconnected with one or more local nodes 104 via a network 100. Thenetwork 100 could for example comprise an optical fiber network of thetype known in the art using dense wave-division multiplexing (DWDM),Synchronous Optical Network (SONET) transport technology or gigabitEthernet transport. In the downstream direction (from the head-endservers or nodes to the CPE 110), this network performs the function ofcarrying digital and analog television signals as well as packetizeddata (e.g., IP) traffic. A cable modem termination system (CMTS) 106located at a local node 104 provides connectivity to the CPE 110 via thecoaxial drop 108. The CMTS interfaces 106 in turn are connected directlyor indirectly to the Internet or IP backbone, thereby providing accessfor the CPE 110 to the Internet (or other internets, intranets, ornetworks) via the cable network infrastructure. Aggregation oftelevision programs that include local and regional programming, orother types of content, occurs at the head-end 102, where these programsare converted into a suitable transport format and a “channel line-up”is created for delivery to the downstream CPE 110.

Referring now to FIG. 1a , one exemplary embodiment of a head-endarchitecture useful with various aspects of the present disclosure isdescribed. As shown in FIG. 1a , the head-end architecture 150 comprisestypical head-end components and services including billing module 152,subscriber management system (SMS) and CPE configuration managementmodule 154, and OOB system 156, as well as LAN(s) 158, 160 placing thevarious components in data communication with one another. It will beappreciated that while a bar or bus LAN topology is illustrated, anynumber of other arrangements as previously referenced (e.g., ring, star,etc.) may be used consistent with the disclosure. The head-endarchitecture 150 may also include a cable-modem termination system(CMTS) if desired.

It will also be appreciated that the head-end configuration depicted inFIG. 1a is high-level, conceptual architecture, and that each MSO mayhave multiple head-ends deployed using custom architectures.

The architecture 150 of FIG. 1a further includes amultiplexer/encrypter/modulator (MEM) 162 coupled to the HFC network 101adapted to “condition” content for transmission over the network. Thedistribution servers 104 are coupled to the LAN 160, which providesaccess to the MEM 162 and network 101 via one or more file servers 170.The VOD servers 105 are coupled to the LAN 160 as well, although otherarchitectures may be employed (such as for example where the VOD serversare associated with a core switching device such as an 802.3z GigabitEthernet device). As previously described, information is carried acrossmultiple channels. Thus, the head-end must be adapted to acquire theinformation for the carried channels from various sources. Typically,the channels being delivered from the head-end 150 to the CPE 106(“downstream”) are multiplexed together in the head-end and sent toneighborhood hubs via a variety of interposed network components.

Content (e.g., audio, video, etc.) is provided in each downstream(in-band) channel associated with the relevant service group. Tocommunicate with the head-end or intermediary node (e.g., hub server),the CPE 106 may use the out-of-band (OOB) or DOCSIS channels andassociated protocols. The OCAP 1.0 (and subsequent) specificationprovides for exemplary networking protocols both downstream andupstream, although the disclosure is in no way limited to theseexemplary approaches.

Referring now to FIG. 2, an exemplary configuration of a packet-switchednetwork useful with the present disclosure is illustrated. Whiledescribed in the context of an Internet Protocol Television (IPTV)network, it will be recognized that the principles of the disclosure canbe extended to other transport modalities and network paradigms.

The network 200 of FIG. 2 effectively operates logically “along side”the in-band content delivery system described with respect to FIGS. 1and 1 a, and shares many common elements. It includes digital satellitereceivers 202, analog satellite receivers 204 and off-air receivers 206deployed within the content (e.g., cable) network in order to receivecontent such as broadcast television programs. This content is thendistributed over the cable network. With respect to the IPTV network,the digital satellite feed received via the receiver 202 is sent to avideo multiplexer 210 that provides one or more digital programs to oneor more video encoders 218 to transcode/transrate or otherwise processincoming digital video streams to a format suitable for loading onto thevideo streaming server.

An Emergency Alert Service (EAS) head-end server subsystem 214 is shownto operate in conjunction with the in-band and IPTV content systemsdescribed above. This subsystem includes a receiver 230 responsible forreceiving emergency alert messages from message feeds (e.g., in the formof RF communications on government designated disaster message broadcastfrequencies), or by other means. The messages or data thus received areconverted into a digital data format suitable for transmission over theIPTV network using a formatting unit 232. The formatting unit 232 alsooptionally regionalizes or localizes the data to allow for “targeted”delivery as discussed in greater detail subsequently herein. Note thatin FIG. 2, while localization and formatting are shown as a singlelogical functional block, actual implementations of these functions maybe on separate (and even disparate) platforms.

The subsystem 214 also contains one or more servers 234 that operate inconjunction with other servers in the network, in a manner describedfurther herein, in order to transmit emergency messages/content to theclient devices 220 over the interposed IP distribution network 216.

The video streaming server 222 and the EAS message server 234 are inturn connected to the Content Distribution Network 216 (which in thecontext of a cable network, may comprise, inter alia, the coaxial “drop”108 of FIG. 1 between the CPE 110 and CMTS 106). Other architecturalelements connected to the content distribution network 216 are shown as“other related servers” 224 in FIG. 2. Client devices 220 (such as PCsconnected to cable modems, wireless user devices in communication withaccess points (APs) or gateways, etc.) are connected to the contentdistribution network and perform the functions of, inter alia, decodingand displaying video and EAS signals.

It will be appreciated that several different configurations of theabove-described IPTV network are possible consistent with the presentdisclosure. For example, the video encoders 218 shown in FIG. 2 may beconfigured to produce one or more bit streams for the same content. Suchbit streams could have different bit rates as a function of suitabilityfor transmission over the IP network (e.g., low, medium and high bitratestreams for various rate services, such as dial-up, DSL and cable modemIP services, respectively), and/or different encoding formats conformingto audio/video encoding standards such as Real or MPEG or Windows MediaPlayer (WMP). Similarly, the EAS head-end server subsystem 214 couldserve the emergency messages or content to the client devices inunicast, multicast or broadcast manner.

It is noted that while localization of emergency messages or video istypically a highly desired feature, this feature may be omitted orobviated in certain applications, such as when all client devices that agiven head-end is serving are in the same emergency alert area. Also,the placement of the localization function within the network can bevaried; including e.g., (i) only at the head-end 150, (ii) partly at thehead-end and partly at the client devices 220, or (iii) exclusively atthe client devices 220.

Furthermore, the emergency alert data received by the network aretypically made available by governmental agencies by broadcasting themat a pre-designated frequency over the air. In some implementations ofcontent distribution networks, these messages may be received in onelocation within the network, and carried over another medium (e.g.,fiber optic or millimeter wave transmission) to other head-ends or nodesof the network. In such embodiments, the EAS receiver 230 may notcontain an explicit over-the-air receiver, but still receive suchmessages.

Localization of Emergency Alert Messages—

Localization refers to “editing” the emergency alert messages or datareceived by the network operator such that (i) the appropriate subset ofclient devices to whom the message may be applicable is able to receiveand decode it, and (ii) other client devices are able to discern thatthe emergency alert message is not targeted for or applicable to them.As but one example, the emergency alert message specification for cablebroadcast (ANSI standard J-STD-042-2002, incorporated herein byreference in its entirety) describes localization in the form of countycode and subdivision.

In an IPTV deployment such as one implemented over a cable data network,the locations of modems to which EAS clients are attached is availableat a network-side server. This may comprise, for example, a MAC addressor device ID associated with a given cable modem, gateway, user device,or the like. Furthermore, “ranging” information may be used to validatean installation of a premises device, based on expected signalpropagation delays (thereby telling the network operator when the devicehas been moved to another location within the network). Such informationcan be taken advantage of when formatting the EAS messages for targetinga specific subset of client devices.

Hence, in one aspect, the present disclosure affords significantcapability in terms of tailoring the delivery of EAS messages toparticular groups of subscribers. For example, the MSO may maintain adatabase of cable modem or gateway device IDs or MAC addresses and acorresponding postal zip code for each such modem/gateway. When antornado alert message is issued by NWS for certain counties or zip codesfor example, the MSO can rapidly access this database to determine whichdevice IDs/MAC addresses to which to route the EAS message. Certain zipcodes may merit a first type of message (e.g., critical warning), whileothers may merit a less dire or different type of alert.

It will be appreciated that information other than zip code can be usedas well (or in conjunction) as a basis for differentiating messagedelivery and/or content, such as e.g., subscriber latitude/longitude,street address, elevation above sea level, etc. For example,commercially available software packages are capable of mapping givenstreet addresses to an elevation map, earthquake/fault/liquefaction map,etc. Hence, the MSO can pre-store such information for each deviceID/MAC address, and hence tailor the alert warnings for a heavy rainstorm primarily to low-lying areas. Radius from a given point orcoordinate may also be used as a targeting or screening criterion (e.g.,every network subscriber within 5 miles of a given coordinate isprovided a first type of warning, while everyone outside 5 miles isgiven a second type of warning). Myriad other such “tailoring”approaches are possible according to the present disclosure.

It will also be appreciated that other information, such as that of atransient nature, may be used for the purposes of tailoring delivery ofemergency data. For example, a wireless (e.g., Wi-Fi) enabled userdevice may associate with an AP in e.g., a location outside of theiraddress of record, for example at a local or distant coffee shop. Theuser device may be associated with a network subscriber, and hence thenetwork operator (e.g., MSO) may wish to provide emergency data to thatuser in situ (i.e., at the coffee shop) under at least twocircumstances: (i) there is an impending emergency affecting the coffeeshop, and (ii) there is an impending emergency affecting the user'spremises. Hence, by identifying the user uniquely, and their “transient”location (in this example, via association with the coffee shop's AP, aGPS receiver on the mobile device, or otherwise), the MSO can tailor orfilter alerts for the foregoing two circumstances. Specifically, in oneimplementation, logic on an MSO or third-party server is used tocorrelate user/subscriber IDs to geographic locations within regionsaffected by emergency alerts, and provide such alerts at the transientlocation. In one variant, the logic evaluates the region affected by theemergency alert against both the user's transient location and theirpremises location, and provides the alert to the user's registeredlocation (e.g., to their DSTB or cable modem or gateway), as well astheir transient location (the latter via e.g., an interposed IP network,such as the Internet, and/or via third party service provider network,such as one providing broadband access to the coffee shop's Wi-Fi AP).

It will also be appreciated the foregoing tailoring can be applied inthe context of familial, employment, or other relationships. Forexample, an emergency alert affecting a geographic area, building,school campus, etc. of a network subscriber can be extended to immediatefamily, co-workers, fellow students, etc. according to one or moreprescribed distribution rules. For instance, the family of an elderlysubscriber whose residence is affected by an emergency may wish to benotified, so that they can render immediate assistance. Suchrules/relationships can be, e.g., specified at the time of accountsetup, periodically updated, etc., so that each subscriber has a currentdistribution “net” associated therewith.

Authentication of Emergency Alert Messages—

The intended end effect of an emergency alert message on a client deviceis disruptive to the viewing of audio/video program or other uses by theuser (i.e., “forced” viewing/hearing of the alert message in whateverform it is delivered). Accordingly, when invoked, the EAS deliverysystem will preempt (or at very least significantly detract from) allother modalities of content delivery. Moreover, “spoofing” of emergencyalerts can be deleterious, and even harmful, to recipients, such aswhere they evacuate their home in response to the spoofed alert. It istherefore critical to provide a method and apparatus that is robust,such that any unauthorized use of the emergency alert subsystem is: (i)prevented from occurring, and (ii) readily detected and defeated in casethe methods of preventing such surreptitious access are somehowbypassed. Such security methods become even more critical when the EASclient application running on the client device is able to force are-tuning of the client device to the emergency alert video stream/feedand/or trigger alert responses of client devices within the consumerpremises network. Thus, by authenticating the EAS, false alarm responsesmay be reduced or eliminated.

FIG. 3 is a signal exchange diagram highlighting two exemplaryembodiments of the present disclosure, wherein the emergency alertmessages received by the client devices are explicitly validated bycommunication between the client device 220 (as represented by the EASprocess 300) and a head-end server process 302 (or alternatively the EASserver process 304).

FIG. 3 shows an emergency alert message transmission 314 by the EASserver process 304 to the client device 220 (and its EAS process 300). Arequest/response pair of messages 316, 318 are also shown, wherein uponreception of the EA message 314, the EAS client 300 requests itsauthentication from a head-end server process 302. In variousembodiments of the disclosure, the head-end server may comprise forexample a digital certificate authority (CA) server, a networkmanagement server associated with a cable modem network, or yet anothertype of server entity adapted for authentication and/or identificationfunctions.

In an alternate embodiment of the request/response authenticationprocess, message exchanges 320, 322 can be used as shown in FIG. 3. Inthis exchange, the EAS client 300 sends a confirmation request back tothe EAS server process 304 at the IP address known to the client toverify that the EAS message was indeed sent by the EAS server process.

Various other embodiments of the message exchange/authentication processare possible according to the disclosure. These include, but not limitedto, use of an encrypted data transmission (e.g., using secure HTTPtransmission), and data hashing techniques, such as those based on keys.Some data networks may also include a “firewall” or other comparablesoftware mechanism that filters messages arriving from outside thenetwork on TCP or UDP ports specifically assigned to EAS messages.

Timing windows or other constraints may also be used to assist inidentifying “spoofed” EAS messages. For example, alerts may be issuedonly at prescribed intervals or times. After consideringpropagation/delivery delays, certain windows of eligibility can beestablished, and local clocking (e.g., SI time reference or the like)can be used to authenticate or filter the message based on time ofreceipt. As a simple example, an MSO may only issue EAS messages tosubscribers on certain temporal boundaries (e.g., only at 00.00 SI timereference), or only at no more than a prescribed frequency (e.g., onceevery 5 minutes). Hence, any alleged EAS events outside of thosecriteria would be at minimum identified or flagged for furtherevaluation.

Myriad other approaches and combinations will be recognized by those ofordinary skill when provided the present disclosure.

Methods—

Various embodiments of the present disclosure are directed to schemesfor providing indications of emergency messages received via a networkinfrastructure to devices, such as those within or associated with aconsumer premises network.

In one embodiment, a consumer premise equipment (CPE) is configured toprovide indications of a received Emergency Alert Message (EAS) messagefrom a cable network infrastructure to devices within a consumerpremises network. Accordingly, a person residing within the consumerpremise may be informed of an emergency even though a device thatdisplays the EAS message (e.g., a television) is powered-off, and thusunable to inform the resident of the emergency. The consumer premisenetwork may comprise a number of different network types andtechnologies. For example, a CPE may be configured with to communicatewith a variety devices within the consumer premises through the use oneor more network interfaces such as those compliant with IEEE. Std802.11, IEEE-1394, Zigbee®, Z-Wave, Bluetooth®, Ethernet, etc.

Referring now to FIG. 4, one embodiment of a generalized method forproviding indications of a received emergency alert message to devicesis disclosed.

At step 402, an alert message is received. In one implementation, thealert message comprises an EAS message received over a managed (e.g.,cable or satellite) network infrastructure at a set top box (STB). TheEAS message is configured with a prescribed format; e.g., a SpecificArea Message Encoding (SAME) header, an attention signal, an audioannouncement, and a digitally encoded end-of message marker. An EASmessage may be transmitted/received only once, or a multitude of times,such as at a prescribed frequency as described supra.

At step 404, an alert response is determined. In one embodiment, thealert response is determined by analyzing the EAS message, and comparingit against one or more alert response rules. The analyzed content of theEAS message may be based on e.g., the entire EAS message, or one or moreportions thereof, and/or capabilities of the devices in which the alertresponse are to be issued. The types of the alert response may beselected from a variety of possible alerts, such as auditory or visualalerts.

In one variant, capabilities of the devices within the consumer premisesnetwork are determined. In one exemplary implementation, the devicecapabilities are determined by one or more queries to the devices, suchas to a hardware registry, API, or other mechanism within the device. Inresponse, the devices will provide the requestor with all or a portionof the devices capabilities. The portion of the devices capabilities maybe limited to auditory and/or visual display functionality. For example,a queried device may comprise a cellular telephone or smartphone. Inresponse to the query, the cellular device may relay devicefunctionality relating to speakers, display, vibration modes, photoflash, or any other auditory/visual functionality contained therein. Thequery may be further configured to obtain functionality of any devicesassociated or otherwise in data communication with the originallyqueried device. For example, the cellular telephone may have otherdevices connected via the cellular telephone's network interfaces (e.g.,LTE, Wi-Fi, Bluetooth®, Universal Serial Bus (USB), IEEE 1394, Zigbee®,Z-Wave, NFC/ISO 14443, etc.). One salient advantage of querying forfunctionality of the associated devices is to expand the number ofpossible devices in which alert responses may be issued, as the issuingentity may not be otherwise able to communicate with the associateddevices, and/or increase the amount of types of alert responsesavailable for issuance.

In another implementation, the capabilities of the devices areselectable by a user. The user may configure the issuing system torecognize and associate various devices via a user interface.Alternatively, the issuing system may determine the available devices,and prompt a user to configure the one or more settings relating to thefunctionality of the available devices.

In another implementation, the device's indigenous systems are queriedto attempt to divine whether the device is actually in use and in thepossession of the user. An emergency alert issued to a device that issitting unattended (e.g., in a user's automobile glove compartment) maybe of little or no utility, or may need to be altered in their delivery.Hence, by accessing indication of activity (e.g., output from thedevice's accelerometer, indicating motion, periodic inputs via the touchscreen display, power-on indications, etc.), the alerts can be tailoredto the operational environment. Consider, for instance, theaforementioned case where the user's smartphone is in their autoglovebox. If it is determined that the device is inactive (e.g., inpower-save mode, and no recent inputs), an otherwise normal visual orvibrational alert notification might be altered or expanded to includeaudio speakers on the smartphone, such that the user has a better chanceof hearing the device while e.g., driving). Similarly, the devices'Wi-Fi or BT interface could communicate with the vehicle's onboardinfo-tainment system, to play the alert out the audio speakers, and/orvia touch-screen in-dash display.

In one variant, the EAS message is analyzed based on the SAME header.The SAME header contains various information relating to the alert eventassociated with the EAS message. For example, the SAME header maycontain information relating to the originating entity for the alert, adescription of the alert event, expected duration of the alert event,date and time the alert message was issued, etc. By analyzing thecontents of the SAME header, the contents may be compared against theone or more alert response rules in order to determine the appropriatealert response. For example, certain categories of alert event mightdictate a more frequent or invasive re-transmission and/or playoutschedule on the target user device, thereby adding to the urgency, asdescribed in greater detail below.

In another implementation, the EAS message is analyzed based on thecontent on the auditory announcement. By analyzing the auditoryannouncement, emergency related content can be derived such as an eventtype (e.g., tornado, fire, earthquake, etc.). Additional information maybe derived such as a perceived severity of the emergency based on theauditory message contents. In one variant, the auditory announcement inconverted into a text format via a speech recognition process. Onceconverted into the text format, the contents of the text may be analyzedbased on keywords associated with emergency type and various aspectsthereof, such as severity. For example, content relating to a fire mayinclude information regarding percentage of containment, and/or rate ofspreading may be derived and used to determine an appropriate alertresponse. Additionally, the content of the text message may be analyzedto determine an approximate and/or actual location of the emergencyevent. By determining the location of the emergency event, rules may beconfigured to compare the location of the event to the location of theconsumer premises. Thus, for example, more proximate emergency eventscan be configured to trigger a different alert response, as compared toa less proximate emergency event based on the one or more alert responserules.

In one embodiment, the one or more alert response rules are determinedby an entity associated with the managed network infrastructure. A CPEresponsible for receiving EAS message from the network infrastructure ispre-programmed with the one or more alert response rules. The CPE may befurther configured to receive configuration updates to modify the one ormore alert response rules. The configuration updates are received overone or more network interfaces of the CPE from the network operator(i.e., via in-band or out-of-band signaling of the cable network) or viaother entities, such as a manufacturer of the CPE, via a networkconnection interface.

In another embodiment, the one or more alert response rules are at leastpartly configurable by a user. In one variant, the CPE is configured toallow a user to directly adjust the one or more alert response rules viaa user interface of CPE. In another implementation, the one or morealert response rules are configurable by a device in data communicationwith the CPE. Thus, alert response rules may be remotely modified by theuser via another device having appropriate permissions. The devicecomprises, in one exemplary illustration, a home automation systemconfigured to control one or more household devices (e.g., lighting,door locks, etc.). The home automation system is configured to receivecommunications from the CPE and other devices within the consumerpremise system. The home automation system may be further configuredwith home security functionality responsible for communicating withvarious security devices, such as sirens, strobe lights, motion sensors,etc., and the latter can even be leveraged for delivery of EASinformation (such as where in the case of an imminent danger, thepremises security alarm siren is activated, without contacting theoutside monitoring service).

In one embodiment, the determined alert response comprises an alertprioritization level. After the one or more alert response rules and EASmessage are analyzed, the associated alert is classified. For example,the alert classification may comprise a multitude of alert priorities,ranging from various levels of higher to lower priorities. Higher alertpriorities may be configured to increase an amount of alert responsestriggered, as previously noted. In addition, the alert proprieties maybe configured to limit the alert configuration options available to theuser. For example, a user may restrict the type of auditory and visualalarm responses for alert priorities with a lower priority. However, ahigh level alert priority may restrict a user's ability to modify theauditory and visual alarms at least partly or even completely, so as toavoid the user inadvertently or intentionally bypassing critical alertfunctions.

In another exemplary embodiment, the determined alert response comprisesone or more commands to trigger execution of the desired alertresponses. The one or more commands are configured to instruct therespective devices to implement the determined alert responses. The oneor more commands do not contain any information relating to the EASmessage or content thereof. Instead, the commands are configured todrive the desired functionalities of the devices within the consumerpremise network. For example, commands may be used to transmit a “turnon using pattern x” command to a “siren module” pre-programmed withdifferent audible output patterns (tones, durations, volumes, syntheticvoices, stored pre-recorded messages, etc.) and/or a “blink at a rate ofy” command to one or more light switches, smart bulbs, “strobe” modules,etc. within the consumer premise network.

At step 406, an alert response is issued. In one embodiment, the issuedalert response comprises issuing an indication of a priority of thereceived EAS. In such an exemplary embodiment, the receiving deviceswithin the consumer are configured to issue a respective response basedon the received alert priority level. Thus, an issued alert response maycontain no actual information related to content of the received EASmessage, but instead trigger auditory and/or visual responses indicativeof the associated event. For example, indications of the emergency eventmay be color-coded, trigger specific auditory alarms, etc. Additionally,the devices in the consumer premise may be configured to issue alertresponses to devices that are associated with the device based on thereceived indication.

In another embodiment, the issued alert responses comprise commandsconfigured to directly activate capabilities of the devices to providethe determined alert responses. The commands may be further configuredto instruct the receiving device to forward and/or issue commands itselfto devices that are in data communication with the receiving device.Thus, the receiving device useable as a proxy to allow commands to beissued to devices in which the issuing entity could not otherwisecommunicate therewith. The commands may be configured to mandate thedevices to perform the determined alert responses. Additionally, thecommands may be configured to allow selectively performance of thealerts associated to the commands by the receiving devices.

Consumer Premise Network Architecture—

Referring now to FIG. 5, an exemplary consumer premise networkarchitecture 500 configured according to the present disclosure isdescribed. In one embodiment, the consumer premise network 500 comprisesa plurality of consumer premise equipment (CPE). At least one CPE 502 isconfigured to receive EAS message from a network 504 (EAS CPE). The EASCPE is configured to analyze the received EAS message and determineappropriate alert responses for a respective CPE. In one implementation,the EAS CPE is configured with an alert rules engine to analyze areceived EAS against one or more alert response rules. The EAS CPE isfurther configured to communicate with various other CPE devices inorder to issue alert commands, including CPEs consisting of auditoryand/or visual display related functionalities.

In one implementation, one of the CPE 502 comprises a device responsiblefor managing and controlling a home automation system (Home CPE), suchas the exemplary IntelligentHome™ home automation system provided by theAssignee hereof. The Home CPE may optionally be configured with one ormore interfaces to communicate with devices outside of the consumerpremise network architecture 500 via, for example, a cellular networkconnection 506. In one implementation, the Home CPE is configured tomodify the alert rules engine of the EAS CPE. The modification may becommunicated via an external entity using a network interface of theHome CPE. Alternatively, the Home CPE is configured with a userinterface to allow a user within the consumer premise network to modifyat least partially the alert rules engine. The Home CPE is furtherconfigured to communicate and/or control certain devices andfunctionalities associated with the premise (e.g., house). Such devicesand functionalities may include, but are not limited to, lightingcontrol, motion sensors, auditory and/or visual alarms. Furthermore,such devices may be directly or indirectly controlled by the Home CPEand be connected thereto over a variety of heterogeneous network types.Additionally, it may be recognized that the EAS CPE and Home CPEfunctionalities are included into a single CPE or has functionalizes asdiscussed herein spread across various ones of CPE.

Additionally, one or more of the CPE 502 of the consumer premise may beconfigured with a supplemental rules engine responsible for implementingcommands received from the EAS CPE. In one implementation, thesupplemental rules engine is configured to interpret a received commandand determine commands to issue on its own to implement the desiredalert responses. For example, a supplemental rules engine may receive apriority level of an EAS message and implement one or more alertresponses associated therewith. In another implementation, thesupplemental rules engine receives commands that direct indicate thealert responses to implement, such as sound an alarm. The supplementalrules engine may be additionally configured to be modifiable by a useror filter out certain received commands to be ignored from an EAS CPE.Accordingly, one advantage of the present disclosure allows for a highlycustomizable system to allow a user within a consumer premise network toselectively design and implement alerts in response to a received EASmessage.

Consumer Premise Equipment

Referring now to FIG. 6, one exemplary embodiment of the consumerpremise equipment 600 (CPE) configured in accordance with the presentdisclosure is described in detail. A CPE 600 in the context of thepresent disclosure generally comprises a computerized device running anoperating system. The CPE 600 includes a processor subsystem 602, memorysubsystem 604, user interface 606, display device 608, and one or morenetwork interfaces 610 including for example an RJ-45 LAN connector withEthernet LAN card, USB ports, IEEE-1394 “Firewire” interface, wirelessinterface (such as 802.11 LAN card, WiMAX 802.16 interface, 802.15 PANinterface, Bluetooth interface), Zigbee, or Z-wave and so forth.

The processor 602 of the exemplary CPE 600 is configured execute one ormore computer programs which enable the above-disclosed functionalitiesas discussed above with respect to FIGS. 1-5. In other words, a computerprogram running on the processor 602 may perform the functions of theherein described alert rules engine (i.e., to analyze a received EASagainst one or more alert response rules, etc.). In another embodiment,the computer program is configured to enable the exemplary CPE 600 toperform the functions of the herein described supplemental rules engine(i.e., to implement commands received from the EAS CPE).

It is further appreciated that the computer programs which enable theaforementioned functionality may be pre-installed on the apparatus ormay be downloaded from a network (such as e.g., the network 216disclosed in FIG. 2).

It will be recognized that while certain aspects of the disclosure aredescribed in terms of a specific sequence of steps of a method, thesedescriptions are only illustrative of the broader methods of thedisclosure, and may be modified as required by the particularapplication. Certain steps may be rendered unnecessary or optional undercertain circumstances. Additionally, certain steps or functionality maybe added to the disclosed embodiments, or the order of performance oftwo or more steps permuted. All such variations are considered to beencompassed within the disclosure disclosed and claimed herein.

While the above detailed description has shown, described, and pointedout novel features of the disclosure as applied to various embodiments,it will be understood that various omissions, substitutions, and changesin the form and details of the device or process illustrated may be madeby those skilled in the art without departing from the disclosure. Thisdescription is in no way meant to be limiting, but rather should betaken as illustrative of the general principles of the disclosure. Thescope of the disclosure should be determined with reference to theclaims.

What is claimed is:
 1. Computerized apparatus configured for use in acontent delivery network, the computerized apparatus comprising: aprocessor apparatus; one or more interfaces in data communication withthe processor apparatus; and a non-transitory computer readable storagemedium with at least one computer program stored thereon, the at leastone computer program configured to, when executed, cause thecomputerized apparatus to: receive event data; identify one or morecomputerized client devices in communication with the content deliverynetwork; determine that at least one first computerized client device ofthe one or more computerized client devices has first capabilities;determine that at least one second computerized client device of the oneor more computerized client devices has second capabilities, wherein thefirst capabilities are different from the second capabilities; formatthe event data into at least a first event command and at least a secondevent command, wherein the first event command is different from thesecond event command; transmit the first event command to the at leastone first computerized client device; and transmit the second eventcommand to the at least one second computerized client device.
 2. Thecomputerized apparatus of claim 1, wherein the at least one firstcomputerized client device comprises a premises device, and wherein thefirst event command causes the first computerized client device to causeexecution of a premises device functionality.
 3. The computerizedapparatus of claim 2, wherein the at least one first computerized clientdevice comprises a lighting device, and wherein the causing execution ofthe premises device functionality comprises causing actuating thelighting device at a predetermined rate.
 4. The computerized apparatusof claim 2, wherein: the event data comprises emergency alert data; theat least one first computerized client device comprises a security alarmsiren; and the causing execution of the premises device functionalitycomprises causing activation of the security alarm siren without contactof an external monitoring service.
 5. The computerized apparatus ofclaim 1, wherein the determination of the first capabilities comprisesdetermination of a plurality of capabilities from data representing acorresponding selection by a user of the first computerized clientdevice, the corresponding selection received via a computerized userinterface associated with the computerized apparatus.
 6. Thecomputerized apparatus of claim 5, wherein the determination of thesecond capabilities comprises determination of a plurality ofcapabilities from data representing corresponding selections by a userof the second computerized client device, the selections of the user ofthe second computerized client device received via the computerized userinterface.
 7. The computerized apparatus of claim 1, wherein thedetermination of the second capabilities comprises transmission of amessage to the second computerized client device, the message configuredto cause a response from the second computerized client device, theresponse comprising data indicative of at least one of the secondcapabilities.
 8. The computerized apparatus of claim 1, wherein thedetermination of the first capabilities comprises a determination thatthe first computerized client device has both (i) a prescribed audiorendering capability and (ii) a prescribed visual display functionality.9. The computerized apparatus of claim 1, wherein the determination ofthe first capabilities comprises a determination of whether: (i) thefirst computerized client device maintains an active wirelessconnection, or (ii) the first computerized client device is in aninactive state.
 10. The computerized apparatus of claim 9, wherein theformatting of the event data into the first event command is based atleast in part on the determination of whether: (i) the firstcomputerized client device maintains the active wireless connection, or(ii) the first computerized client device is in the inactive state. 11.The computerized apparatus of claim 10, wherein the at least onecomputer program is configured to, when executed, cause the computerizedapparatus to: based at least in part on a determination that the firstcomputerized client device is in the inactive state, cause utilizationof a first command format which is configured to cause activation of anexpanded set of notification mechanisms as compared to a first commandformat used when a determination that the first computerized clientdevice is not in the inactive state.
 12. The computerized apparatus ofclaim 1, wherein: the determination of the first capabilities comprisesa determination that the first computerized client device is in datacommunication with a third computerized client device; and the firstevent command is configured to cause the first computerized clientdevice to transmit a third event command to the third computerizedclient device.
 13. The computerized apparatus of claim 1, wherein the atleast one computer program is further configured to, when executed,cause the computerized apparatus to evaluate the event data, theevaluation comprising an evaluation of a header of the event data todetermine at least a category of an event, and wherein the formatting ofthe event data is based at least in part on the determined category ofthe event.
 14. The computerized apparatus of claim 1, wherein theformatting of the event data is based at least in part on thedetermination of the first capabilities.
 15. The computerized apparatusof claim 1, wherein the at least one computer program is furtherconfigured to, when executed, cause the computerized apparatus toevaluate the event data, the evaluation comprising authentication of theevent data, the authentication of the event data comprising confirmationthat the event data originated from a server authenticated to thecontent delivery network as a valid event data source.
 16. Thecomputerized apparatus of claim 15, wherein the authentication of theevent data further comprises use of an encrypted data transmission. 17.A computerized method for providing emergency event data to a pluralityof computerized client devices associated with a respective plurality ofusers, the computerized method comprising: receiving emergency eventinformation associated with a prescribed geographical location;formatting the emergency event information into at least a first type ofemergency message; determining that a first device of the plurality ofthe computerized client devices meets a prescribed relationship to theprescribed geographical location, wherein the first device is associatedwith a first user; determining that a second device of the plurality ofthe computerized client devices does not meet the prescribedrelationship to the prescribed geographical location; determining that asecond user associated with the second device of the pluralitycomputerized client devices is affiliated with at least one of (i) theprescribed geographical location, or (ii) the first user; andtransmitting at least the first type of emergency message to the firstdevice and the second device.
 18. The method of claim 17, wherein: theformatting the emergency event information into at least the first typeof emergency message comprises formatting the emergency eventinformation into at least the first type of emergency message and asecond type of emergency message; and the transmitting at least thefirst type of emergency message comprises transmitting the first type ofemergency message to the first device, and the second type of emergencymessage to the second device.
 19. The method claim 17, wherein thedetermining that the second user associated with the second device isaffiliated with at least one of (i) the prescribed geographical locationor (ii) the first user, comprises determining via a user database thatthe second user has a familial or employment relationship to the firstuser.
 20. The method claim 17, wherein the determining that the seconduser associated with the second device is affiliated with at least oneof (i) the prescribed geographical location or (ii) the first user,comprises determining via at least a user database that the second userhas previously indicated an affiliation to a premises meeting theprescribed relationship to the prescribed geographical location.
 21. Acomputerized network apparatus configured for distribution of event datato a plurality of computerized client devices, the computerized networkapparatus comprising: processor apparatus; one or more data interfacesin data communication with the processor apparatus; and storageapparatus in data communication with the processor apparatus, thestorage apparatus having at least one computer program stored thereon,the at least one computer program configured to, when executed on theprocessor apparatus, cause the computerized network apparatus to:receive event data associated with a prescribed geographical location;format the event data into a first type of event command; determine thata location of a first device of the plurality of computerized clientdevices meets a prescribed relationship to the prescribed geographicallocation, wherein the first device is associated with a first user;determine that a location of a second device of the plurality ofcomputerized client devices does not meet the prescribed relationship tothe prescribed geographical location; determine that a second userassociated with the second device of the plurality of computerizedclient devices is affiliated with at least one of: (i) the prescribedgeographical location, or (ii) the first user; and cause transmission ofat least the first type of event command to the first device and thesecond device.
 22. The computerized network apparatus of claim 21,wherein the causation of transmission of the at least first type ofevent command to the first device and the second device is based atleast in part on: a) the determination that the location of the firstdevice of the plurality of computerized client devices meets theprescribed relationship to the prescribed geographical location; and b)the determination that the second user associated with the second deviceof the plurality of computerized client devices is affiliated with thefirst user via data previously submitted by the first user indicatingassociation of the second user to the first user.
 23. The computerizednetwork apparatus of claim 21, wherein the at least one computer programis further configured to, when executed on the processor apparatus,cause the computerized network apparatus to access user configurationdata associated with the first device, the user configuration data atleast in part specifying a user interface (UI) modality to be utilizedfor communicating event data; and wherein the formatting of the eventdata into the first type of event command comprises formatting accordingto a prescribed message protocol that is consistent with the UI modalitybased at least partially on the user configuration data.
 24. Thecomputerized network apparatus of claim 21, wherein the at least onecomputer program is further configured to, when executed on theprocessor apparatus, cause the computerized network apparatus todetermine a classification of the event data; and wherein the formattingof the event data into the first type of event command is based at leastpartially on the classification of the event data.
 25. The computerizednetwork apparatus of claim 21, wherein the determination that the seconduser is affiliated with at least one of (i) the prescribed geographicallocation, or (ii) the first user, is based at least on accessing of anetwork subscriber database in communication with the network apparatus,wherein the network subscriber database comprises data submitted by thefirst user, the submitted data indicating at least one of (i) an addressof the second user; or (ii) a prescribed familial relationship betweenthe first user and second user.
 26. The computerized network apparatusof claim 21, wherein the at least one computer program is furtherconfigured to, when executed on the processor apparatus, cause thecomputerized network apparatus to: determine that at least one of thefirst device or the second device comprises a mobile computerizeddevice; and based at least on the determination, cause encapsulation ofthe first type of event command according to an Internet Protocol.